Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000054_owner-urn-ietf _Wed Mar 26 02:05:30 1997.msg

Internet Message Format | 1997-04-01 | 7KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id CAA05681
    for urn-ietf-out; Wed, 26 Mar 1997 02:05:30 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id CAA05676
    for <[e-mail]>; Wed, 26 Mar 1997 02:05:26 -0500 (EST)
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA25662  (mail destined for [e-mail]); Wed, 26 Mar 97 02:05:24 -0500
Received: from montana (transitory143.lanl.gov [128.165.7.89]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id AAA08237; Wed, 26 Mar 1997 00:05:18 -0700 (MST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 26 Mar 1997 00:04:18 -0700
To: "Karen R. Sollins" <[e-mail]>
From: "Ron Daniel, Jr." <[e-mail]>
Subject: Re: [URN] comments on Sollins' requirements draft
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
Reply-To: "Ron Daniel, Jr." <[e-mail]>
Errors-To: [e-mail]

At 05:54 PM 3/24/97 -0500, Karen R. Sollins wrote:
>Ron,
>
>[...] here's what you said:
>
>
>   This implicit establishment of the security policy that must be obeyed
>   by URN resolvers shows up in several other places. There are many
>   sentences where you say that something "must" exist which I would
>   like to change to saying "must be capable of supporting". For example
>   you say that "There needs to be an authoritative version of each hint,
>   and it must support change control limited only to those principals
>   with the right to modify it". I would prefer a different wording:
>   "Each resolution hint shall have an authoritative instance. It
>   must be possible to restrict changes to the authoritative hint
>   according to the security policy of the organization issuing the hint.
>   Propagation of changes to the authoritative version to any sites mirroring
>   it must be capable of being carried out in a fashion consistent with
>   the security policy governing the operation of the mirroring service."
>   (Actually, I would prefer something less awkward, but I digress. :-)
>
>And my questions are:
>
>1) What did you mean by "resolution hint"?  My suspicion is that you
>meant a hint that leads to a resolution server, and I will assume that
>for my real question, but I realized that I'd better be sure we're on
>the same wavelength.

I think it applies to both information that isused to find a resolver
and information at the resolver that gets us to the resource.

>2) Is it necessary (and this a question you could have asked of me as
>well) that there be an authoritative version of every hint?
>Personally I don't think so.  I believe that there may be hints that
>are intended just to be helpful, but non-authoritative.  I make a copy
>of a resource and make it available to anyone who cares to use it.  I
>put a hint out.  I may not want to be viewed as "authoritative" in any
>way and it certainly doesn't come from anyone who has authority over
>the resource.

That's not what I said. I said that the *hint* has an authoritative
instance, not that the hint *was* authoritative for the resource. For
example, if you have put up a local copy of a resource, and issue a hint
telling people where to find that copy, and I copy your hint, I have a
non-authoritative version of the hint. You have issued the authoritative
version of the hint that gets people to your local copy of the resource.

However, with that clarification out of the way, I'm not positive that
every hint needs to have an authoritative version although I suspect
that is the case.

>(I think not, so in that sense, I think both of us went
>overboard a little.)

Overboard? Us?  Surely not!  ;-)

Saying "may" instead of "must" seems the appropriate thing to do
right now.

>3)  as I read your
>suggested re-writing the RDS must provide whatever security policy
>each organization wants (with no restrictions) for its hints.

Clearly this is impossible. However, I think that we can make a
good stab at providing the tools that are needed in most reasonable
security policies. For example, if an RDS proposal required all
transactions to be encrypted with DES, I would find that objectionable.
If it allowed transactions to be encrypted using an arbitrary
encryption technique, that would be fine. Then we could use specialized
encryption algorithms.

>believe that we can only take a less restrictive position and say that
>there are certain policies and levels of security that an RDS can
>provide and an organization can choose among them.

There are certain tools, such as signatures, key-exchanges, and
encryption. For any of these tools there are a set of algorithms
that could be used (DES vs. IDEA for encryption, etc.). RDS proposals
should provide a set of tools, and indicate a way for different algorithms
for those tools to be identified. Basic tools are well-known and most
security policies (not all) can be built from them.

Actually saying there are pre-defined policies and levels is different.
That is telling me a lot more about what I must and must not do, and
it is *totally* objectionable to my organization. We have particular
procedures we must follow. They will never be proposed as IETF standards.
Nevertheless, they are built on general tools, such as key exchange
and encryption.

>If these [security policies and levels] do not
>provide the degree and type of security that the organization feels it
>needs then I guess they won't use our service.

Karen, security policies change at organizational boundries. Nobody is
going to use an RDS that mandates how they will and will not secure
their information.

>But, I don't believe
>that we can make the unconditional requirement that says, "It must be
>possible to restrict changes to the authoritative hint according to
>the security policy of the organization issuing the hint."  Is that
>really what you meant to say?

With the understanding that not all security policies can be implemented,
yes.

>4) One last minor question about the following sentence, "Propagation
>of changes to the authoritative version to any sites mirroring it must
>be capable of being carried out in a fashion consistent with the
>security policy governing the operation of the mirroring service."
>Shouldn't this                                 ^^^^^^^^^
>
>be "mirrored"?

Probably.


Regards,
Ron Daniel Jr.              voice:[phone]
Advanced Computing Lab        fax:[phone]
MS B287                     email:[e-mail]
Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545